Intellectual property (IP) piracy and other forms of potentially injurious activities are a major concern in many operating or computing environments. Often, microcontrollers, for example, do not offer trusted execution environments for executing proprietary or confidential routines, due to the configuration of the hardware. For instance, the architecture of the hardware may be based more on economical design considerations, particularly when the hardware is to be deployed in an industrial application. This can be problematic, when considering the potentially exposed environments that such microcontrollers may be operating within. Valuable IP assets such as firmware, software, data, and the like may be vulnerable to attack in these situations.
Proposed solutions often include duplication of resources, which may include additional hardware components or systems. For example, a system-on-chip (SoC) may include additional “secure” components (for digital rights management purposes, for example) in addition to like general purpose components on the chip. Secure components may only be used by trusted applications in a secure environment, for example. Such secure components may include clocks, interrupt controllers, keypad controllers, DMA modules, memory, and the like. In general, resource duplication entails additional die size and increased power consumption.
In other proposed solutions, designed time-partitioning may be used to switch modules from a non-secure mode to a secure mode and back, as needed to run secure applications. However, once a module is temporarily assigned to a non-secure application or to a secure application, the whole module is generally unavailable to the other “world” (e.g., secure applications/routines or non-secure applications/routines, respectively) for a time, until it is relinquished by the assigned application. This is generally true, even if the module includes several functional blocks, capable of being used concurrently and independently. In such a situation, many of the functional blocks of the module may be idle (a majority, for example), while the remainder of the blocks of the module (a few, for example) are being used by the assigned application. This technique can limit the range of applications and/or use cases for the design and can be inefficient.